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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document specifies the user plane protocol used between two Media Gateways in the CS core network. 
Through out the present document this protocol shall be referred to as the Nb UP protocol. The Nb UP protocol is for a 
large part identical to the lu UP protocol (see 3GPP TS 25.415 [2]), and only the differences between the two protocols 
are specified. This specification defines the applicability of the UP, as defined in 3GPP TS 25.415 [2], for the Nb 
interface only. 

Given that the Nb UP uses the same PDU types as the lu UP, the term luFP is used to refer to the common framing. 

For the purpose of the present document, any occurrence of the term 'Tu UP" in the corresponding sections of 3GPP TS 
25.415 [2], shall be interpreted as "Nb UP". 
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Scope 



The present document specifies the user plane protocol of the bearer used between two MGWs within the BICC-based 
CS core network, called the Nb UP protocol. The present document assumes the implementation of the split between 
call control and the bearer transport and control, as specified in 3GPP TS 23.205 [1], see figure 1. Note that the present 
document does not preclude an implementation of a combined MSC Server and MGW. 
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Figure 1 : CS core network logical architecture 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

Definitions used in the present document are listed in 3GPP TR 21.905 [6]. 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

lu Interface between the RNS and the core network. It is also considered as a reference point. 

Nb Interface between media gateways. 

luFP lu Framing protocol 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AAL 

AAL2 

ATM 

CN 

CNL 

CS 

FFS 

IPTI 

luUP 

MGW 

PDU 

RTP 

SAP 

SDU 

SRNC 



ATM Adaptation Layer 

AAL Type 2 

Asynchronous Transfer Mode 

Core Network 

Core Network Layer 

Circuit Switched 

For Further Study 

Inter PDU Transmission Interval 

lu interface User Plane 

Media GateWay 

Protocol Data Unit 

Real-time Transmission Protocol 

Service Access Point 

Service Data Unit 

Serving Radio Network Controller 



4 User Plane 

4.1 General aspects 

The Nb UP is located in the user plane of the CS core network over the Nb interface. It is used to convey data between 
MGWs. 

The Nb UP protocol shall be initiated at one MGW and acknowledged by the adjoining MGW. 

The Nb UP framing is identical to the lu UP framing, i.e., the same PDU types are valid for both protocols. 

Figure 2 shows the logical location of the Nb UP protocol layer in relation to the Nb interface. 
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Figure 2: Nb UP protocol layer occurrence in overall architecture. 

4.2 Operational and Functional Aspects 

There are two modes of operation for the Nb UP: 

- Transparent mode; 

Support mode for predefined SDU size. 

The two modes of operation follow the definition of the corresponding lu UP modes of operation, as described in 3GPP 
TS 25.415 [2]. 

Support mode version 2 is mandatory on the NbUP interface. Support mode version 1 is not required at the Nb but may 
be used if both MGWs support it, as a result of the version negotiation during the Initialisation procedure. 



5 Transparent Mode 

This mode of operation is identical to that of the lu UP protocol, see the corresponding section in 3GPP TS 25.415 [2]. 

6 Support mode for predefined SDU sizes 

6.1 General 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.2 Nb UP protocol layer services in Support Mode 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.3 Services expected from the Transport Network Layer 

See the corresponding section in 3GPP TS 25.415 [2]. 
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6.4 Functions of the Nb UP protocol layer in Support IVIode 

6.4.1 Functional model of the Nb UP protocol layer in Support Mode 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.4.2 Frame handler function 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.4.3 Procedure control functions 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.4.4 Non Access Stratum data streams specific functions 

See the corresponding section in 3GPP TS 25.415 [2]. 



6.4.4.1 



Frame quality classification 



6.4.4.1.1 



General 



On the Nb UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is 
based on frame classification on the preceding link and the setting of the attribute "Delivery of erroneous SDUs". The 
MSC server shall indicate the value of the attribute "Delivery of erroneous SDUs" see 3GPP TS 29.232 [3]. 

Figure 4 shows the main input and output information for the frame quality classification function on the Nb UP. 
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Figure 4: Frame quality classification in Nb UP 
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6.4.4.1 .2 Handling of FQC information 

The handling of FQC shall be as specified in Table 1 . 



Table 1. FQC handling in Nb UP protocol, receiving side 



Input 


Action 


Delivery of erroneous 
SDUs 


FQC in received 
PDU 


Payload CRC 


'yes' or 'no' 


'good' 


OK 


Leave FQC unchanged. Forward 
SDU and FQC to upper layer 


'yes' 


'bad radio' 


OK 


Leave FQC unchanged. Forward 
SDU and FQC to upper layer 


'yes' 


'good' or 'bad 
radio' 


Not OK 


Set FQC to 'bad'. Forward SDU and 
FQC to upper layer 


'yes' 


'bad' 


Any 


Leave FQC unchanged. Forward 
SDU and FQC to upper layer 


'no' 


'good' 


Not OK 


Drop SDU 


'no' 


'bad' or 'bad radio' 


Any 


Not applicable. SDUs are dropped at 
a previous link. 


'no-error-detection- 
consideration' 


Any 


Any 


Leave FQC unchanged. Forward 
SDU and FQC to upper layer 



The FQC handling in the Nb UP protocol entity on the sending side is as follows: 

• When the upper layer indicates an FQC value in the Nb-UP-DATA-Request message, an FQC shall be set in the 
PDU as indicated by the upper layer. If the upper layer does not indicate an FQC value, the FQC in the PDU shall 
be set to 'good'. 

• When the upper layer indicates an FQC with the value 'bad' to the Nb UP protocol layer, the Nb UP support 
functions may generate an erroneous payload CRC. 

An MGW may ignore the settings of the "delivery of erroneous SDUs" property of the 3GUP package if the MGW 
passes frames transparently through the UP entities as described in 3GPP TS 29.232 [3]. 



6.5 Elementary procedures 
6.5.1 Transfer of User Data procedure 



6.5.1.1 



Successful operation 



See the corresponding section in 3GPP TS 25.415 [2]. For the purpose of the present document, the MGW replaces the 
function of the SRNC and the CN, and the Nb replaces the function of the lu. 

When the MGW provides the Frame Number IE it shall be based on time according to the handling on lu (see 3GPP TS 
25.415 [2]) for conversational and streaming traffic class. 

NOTE: The luUP Frame Number IE is based on time also and therefore no interworking of this IE is required. 



6.5.1.2 



Unsuccessful operation 



See the corresponding section in 3GPP TS 25.415 [2]. For the purpose of the present document, the MGW replaces the 
function of the SRNC and the CN, and the Nb replaces the function of the lu. 

6.5.2 Initialisation procedure 
6.5.2.1 Successful operation 

See the corresponding section in 3GPP TS 25.415 [2]. 
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When an Nb UP layer protocol entity receives an initialisation status request from the upper layer, it shall start the 
initialisation procedure. See 3GPP TS 29.232 [3], concerning the overall initialisation process. When an Nb UP layer 
protocol entity receives an initialisation message it shall acknowledge this message and indicate to the upper layer that 
an initialisation message has been received. When an Nb UP layer protocol entity receives a positive initialisation 
acknowledgement it shall indicate to the upper layer that a positive initialisation acknowledgement has been received. 

6.5.2.2 Unsuccessful operation 

See the corresponding section in 3GPP TS 25.415 [2]. A negative acknowledgement triggers a repetition of the 
initialisation message. After N inix unsuccessful repetitions, the initialisation procedure is terminated. 

6.5.3 Rate Control 

6.5.3.1 Successful operation 

See the corresponding section in 3GPP TS 25.415 [2]. When an Nb UP protocol entity receives a rate control message 
over the Nb interface, it shall provided an indication of the rate control to the upper layer. The rate control indication is 
acknowledged on request from the upper layer. 

6.5.3.2 Unsuccessful operation 

See the corresponding section in 3GPP TS 25.415 [2]. Depending on the error cause, a negative acknowledgement is 
either reported in a status indication to the upper layer, or it triggers a repetition of the control command. After N rc 
unsuccessful repetitions, the rate control procedure is terminated. 

6.5.4 Time Alignment 

6.5.4.1 Successful operation 

See the corresponding section in 3GPP TS 25.415 [2]. When an Nb UP protocol entity receives a time alignment 
command over the Nb interface, it shall indicate the time alignment to the upper layer. The time alignment is 
acknowledged on request from the upper layer. 

6.5.4.2 Unsuccessful operation 

See the corresponding section in 3GPP TS 25.415 [2]. Depending on the error cause, a negative acknowledgement is 
either reported in a status indication to the upper layer, or it triggers a repetition of the control command. After N ta 
unsuccessful repetitions, the time alignment procedure is terminated. 

6.5.5 Handling of Error Event procedure 

6.5.5.1 Successful operation 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.5.5.2 Unsuccessful operation 

See the corresponding section in 3GPP TS 25.415 [2]. 

6.6 Elements for Nb UP communication in Support mode 

See the corresponding section in 3GPP TS 25.415 [2]. 
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6.7 Handling of unknown, unforeseen and erroneous protocol 
data 

See the corresponding section in 3GPP TS 25.415 [2]. 

7 Communication Primitives for the Nb UP protocol 

layer 

7.1 Modelling Principle 

See the corresponding section in 3GPP TS 25.415 [2]. 

7.2 Primitives towards the upper layers at the CNL-SAP 

See the corresponding section in 3GPP TS 25.415 [2]. 

7.3 Primitives towards the transport layers at TNL-SAP 

7.3.1 General 

Access to the Transport network Layer is performed through a generic SAP: TNL-SAP. 

When the Transport Network upper layer consists of AAL2, the TNL SAP maps to the AAL-S AP which allows 
communication to be performed using specific AAL primitives. 

When the Transport Network upper layer consists of RTP/UDP/IP, the TNL-SAP maps to the services provided by 
IETF RFC 1889 [7]. 

The choice of communication, specific or generic, through the TNL-SAP is fixed by the Core Network Layer control 
plane logic. This choice of communication is based on the requirements placed by, e.g. the RAB characteristics, the 
core network domain requesting the RAB establishment or other operator's choice. 

7.3.2 ATM/AAL2 based Transport Layer 

7.3.2.1 General 

When the Nb UP protocol layer uses the services of an ATM/AAL2 transport, it shall use an established AAL2 
connection for transferring frames between the peer TNL-SAPs at both ends of the Nb User plane access points. The 
Transport Network Control Plane over the Nb interface handles the signalling to establish and release the AAL2 call 
connections. 

7.3.2.2 AAL2 Service Primitives used by the Nb UP protocol 

AAL2 services and primitives used at the Service Access Point from the AAL2 layer are shown in table 3. 
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Table 4: AAL2 primitives and parameters 



Primitive 


Type 


Parameters 


Comments 


SSSAR- 
UNITDATA 


Request 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


SSSAR- 
UNITDATA 


Indication 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


NOTE: The setting of this field is set to not used i.e. decimal value 26 according to ITU-T 
Q.366.1 [8]. 



These primitives are to be used in the Nb UP. 

The Transport Network control plane is as specified in 3GPP TS 29.414 [4]. 

7.3.3 GTP-U based Transport Layer 

Not apphcable. 

7.3.4 RTP/U DP/IP based Transport Layer 

When the Nb UP protocol layer uses the services of an RTP-based transport, it shall use a dynamic payload type that 
was negotiated for the connection for transferring Nb UP frames between the two endpoints at both ends of the Nb User 
plane access points. This dynamic payload type is negotiated using the specified bearer control protocol, 3GPP TS 
29.414 [4]. 



8 



Evolution of Nb UP Protocol 



See the corresponding section in 3GPP TS 25.415 [2]. 
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